2026-02-03

Beginning Update

Began fleshing out a concept of the UI, what the main screen would look like during a game. Not a whole lot of interesting decisions to make here, just learning the syntax and trying to find out what Widget is best used in what scenario. Do I use a Container or ConstrainedBox? Is this a ListView or a standard Column, that sort of thing.

Also realized my understanding of Stateful widgets was… less than perfect. That TurnDirector and TimeDirector are not going to be widgets. I’ll dig into it a bit more, because I won’t make that mistake twice. That being said, right now, it looks like I’ll be using the Providers. The logic itself isn’t going to change, I’m still going to have a TurnDirector and a TimeDirector that manage all of the complicated stuff. But they aren’t widgets, they’re just regular classes, and they’ll be distributed through Providers. That’s the goal. We’ll see how well this ages.

2026-02-02

The Groundwork

Alright, I dug into Flutter a bit, refreshed myself on it’s particular attitude towards development, and here we go!

Flutter breaks things into stateful and stateless widgets, and that’s enough of a distinction to where I think I should sit down and think about where I want all of my components to end up. I believe the most important part of this is figuring out what the primary stateful widgets I am going to need are, as they’ll be handling the processing.

Stateful Widgets

Turn Director

This, to my own great surprise, will handle turns. While passing turns would be simple, it also needs to handle out of order turns, such as those that might be present in Magic the Gathering, when a player “responds” to another player’s actions. This complicates things a bit, but as always, the real issues with come from how the users may interact with it.

For instance, a possible issue I may encounter is if users tend to use both the “End Turn” button and the Player List. These sort of cases will be tackled later, after the app is working.

Basic requirements:

• Start and end game functionality. (Should trigger the Time Director to start as well)
• Ability to add players
• Keeps track of the current player, and the current round.
• Tracks whether the turn is “Out of Order” (OOO) or standard. If a turn is OOO, it will cause certain Widgets to update their functionality.
• Determine who goes next, based on initial ordering in the application.
• Sends turn start and turn end information to the Time Director
• Is able to rotate through turns

Time Director

This could, arguably, be merged in with the Turn Directory, but I believe it is different enough that it warrants its own Widget. Turn Director is probably getting cramped by now. It will recieve turn start and turn end signals from the Turn Director, along with the user id of the current player. It holds onto all of the turn information, and will pass it to whatever needs it.

Basic requirements:

• Keeps track of the amount of time passed.
• Saves the length of time each turn took for each player.
• Can pause

Data Director

At this point I’m just calling every stateful widget a director. This one, if implemented (Still deciding) would save the data of a game to the device, so that past games could be reviewed.

Other Widgets

Most, if not all, of the remaining pieces should be display only. While they are still deserving of some forethought, it’ll be more productive to just get my hands in the sand and try stuff out. I’m still learning how this all works after all.

2026-02-01

The Motivation

While playing some card games (Magic the Gathering) with my friends, I notice that our games were taking an exceptionally long time. More games in a shorter amount of time would be preferable, and I wanted to know where the biggest hang-up was. This got me thinking about making a turn timer, to track how long each player took. These sorts of apps exist already, but there were several other features I wanted that I did not find on the apps I checked.

The General Features

• A timer that tracks how long turns have been going for.
• Arbitrary number of players
• Including “out of game” players. Players who are not in the turn order, but can be selected manually.
• Post game analsis visuals, such as a bar chart of turn lengths, a pie chart of which player took the longest, etc.
• Presets for easy game starts.

The Stack

To be quite honest, a web app would’ve been the simpliest option. It’d leverage all of the stuff I’m learning as I build my website, and wouldn’t require me to learn how to develop for a phone.

But that’s also boring, and this is a personal project so ‘time to production’ isn’t an issue.

After thinking about my choices, I decided on Flutter. There are a few reasons for this. Firstly, I’ve actually experimented with Flutter before. It was just the tutorial they have, but it gave a lasting impression. Secondly, there’s a lot of leg work done already in Flutter, and I enjoy the way it handles it’s construction of Widgets. You want a centered item? Wrap it in a Center() widget, and it does what it says on the tin. Lastly, as a more recent arrival, it has several of the assumptions of modern UI built into it, things like responsive UI, the various menus we’ve all come to know, app bar, side bar, all of those things exist as an immediate Widget to add, because these styles of apps are exactly what Flutter wants to be used for.